BBS in a Box 4/BBS in a Box - Macintosh - Volume IV (January 1992) (BBS in a Box).iso/Files/Prog/N-P/NAOTO HORII ON MAZ

Text File | 1991-07-16 | 7.1 KB | 123 lines | [ttro/ttxt]

Brussels, July 15, 1991.

I'd like to present my apologies to all the users who were inconvenienced
by the expiration date feature of MaxAppleZoom.
I've heard there's been a lot of harsh one-sided criticism about this on
the net, and I'd also like to try to explain my position.
It wasn't planned that users would stumble like this upon this feature:
When I wrote v1.3 - in mid-1990 - I expected I'd be able to release a new
version in time to avoid any service disruptions.  I wanted the next
version of MAZ to be System 7-compatible, and I - like many ? - was led to
believe by Apple's announcements that System 7 would be available in late
1990 or early 1991 at the latest.

I was only able to get hold of a copy of System 7 in late May, and by early
June a nearly final version of MAZ v1.4 was completed.  This was several
months behind my initial schedule.  With only a few days left before the
expiration date of v1.3, the program was obviously to be sent as quickly as
possible to all the interested parties, but I couldn't do it for the
following two reasons:
1- The motherboard of the Mac I'm using choose this rather innoportune
moment to die, making disk duplication rather difficult.  The dealer tells
me that the motherboard has to be replaced.  It looks like component-level
repair is not yet available in Belgium.  This is a quite costly repair and
I'm afraid the expense cannot be reasonably justified for a home computer.
2- While I was developing MAZ, I had to postpone a _lot_ of important work,
and the backlog was becoming critical.  Although I knew I'd be in deep
trouble if I didn't ship the program in time, there was simply no choice.
I feel a morally compelling sense of duty towards my registered users, but
the actual amount of money involved is rather modest and I definitely
cannot mix up my priorities.  We shareware authors tend to understate the
true source of the financial backing of our product, and thus users tend to
notice it only when there's competition for time between our normal and
shareware-related activities.

But there's a more important perception gap between the author and the
users than the merely financial aspect.  That is one about the quantity of
time available.  Let's not forget that to be able to spend some of our time
toying with computers to write and maintain shareware, we authors must
spend a far larger amount of time doing more important, "real" work.  I
received _really_ nice and heartwarming letters from my registered users,
and I very much would have liked to respond to every one of them, but I had
a dilemma: given the limited time I have available for shareware-related
activities, do I choose to spend it writing letters, or do I rather try to
show the registered users my appreciation by concentrating my efforts to
enhance MAZ and make sure it remains compatible with Apple's System
upgrades ?  I chose the latter option, because v1.4 needed far more
resources than I had foreseen, and usage time of some borrowed equipment
had to be optimized to keep the development costs down.

I usually cashed rather quickly the payments I received,  but v1.4
development was proving to be too difficult and time-consuming.  System 7
still wasn't shipping and my other activities put _heavy_ demands on my
time.  Once I had doubts that I'd be able to create a System 7-compatible
MAZ, I could no longer cash the payments I received.  The burden MAZ put on
me made attractive the prospect of killing it and refunding the money of
the previous registered users.  Time and money were very tight, and this
explains my silence during the past "few" months.

I think the expiration date caused a scandal because of the following
reasons:
- I wasn't able to develop and send in time an updated version of the
program to the users who paid their shareware fee.
- There was no warning in the documentation, and MAZ's death troubled a lot
of people.  Maybe there should have been a warning, but I first wanted to
see how many spontaneous payments I'd receive.

I noticed, reading the messages on the net, that some people implicitly tend
to assign a very high value to their own time, and they couldn't care less
about the amount of time authors spend to develop programs.  I am a normal
person, and I don't see why the time I spent to maintain MAZ for my
registered users - and "some" other people are benefiting too - should have
an insignificant value.
In v1.4 I've kept most of my promises I made in the documentation of the
previous versions: System 7 compatibility, a clean, noise-less monochrome
mode, support for a 24-bit video card and multiple-video card
configurations...
Granted, the program didn't ship in time and users had to switch back to a
640*480 screen.  But - as mentioned above - I think some people haven't the
faintest idea about what it takes to take a conceptual idea like MAZ and
implement it in a _reliable_ and transparent product, perhaps because the
software is rather easy to use.  MAZ development and maintenance took
several hundred hours, and I'm getting tired of the discipline I had to
impose myself since releasing MAZ to scrape together that much time.  There
are also a _lot_ of other things I should have done or wanted to do during
that period, not to mention the adverse effects it had on my social life.
And if at my first failure the majority of the users gang up to treat me as
a scoundrel, I'm definitely not getting a very good deal.

I still think that an expiration date - if it's managed correctly -  is an
acceptable way to suggest to users to re-evaluate the usefulness of the
program.  This scheme is often used in software for large computers and
causes minimal inconvenience compared to other protection methods.
Let's note that:

- There is now a warning in the documentation.
- The expiration date forces me to create and release updated versions to
keep the program alive and all users benefit from it.  As Apple probably
won't release System 8 before a couple of years, I'll be able to better
control the development schedule.
- If I'm definitely fed up with MAZ, a commercial publisher could take
charge of the project and expect some return from an unsaturated market.
The firm will need it.  As even equipment repair was difficult to finance,
it won't probably be easy, even for a commercial operation, to purchase
equipment and pay for its maintenance, and pay decent salaries to a person
responsible for distribution/production/user support and an engineer who
will maintain and develop the program.  And I wonder why an engineer would
want to waste his time doing such a boring job.  Advertisements and
packaging costs won't probably be negligible, either.  The author would
like to get part of the revenue, too ( Why not ? )    As the market isn't
probably that large for a program like MAZ, any business plans a small
publisher might draw up has thus to be pretty good and credible.

Some people disliked the fact that I'm using a P.O. Box as my mailing
address.  A P.O. Box is a more secure way to receive mail, especially
during the periods I'm not in Belgium.  Also, I've heard that several
locations in Belgium were burgled after their addresses had been published
in a local Mac journal and I'm not willing to run that risk.

Naoto Horii.